\subsection{Representing the Dynamic State}
\label{sec:application-state}

To enable fine-grained policy specification, \SAR constantly maintains a minimal representation of the application's dynamic state and the rules current status. This is particularly useful for rules like \textsf{R1}, which requires to evaluate the dynamic value of an instance field storing the patients treated by a given doctor, to evaluate if he can consult a medical file. It is also required if security rules depend explicitly on other rules' status: e.g., \textsf{R3} is an obligation activated only when \textsf{R2} is violated. Security rules can also require tracking down a value throughout a call chain: an instance field value can participate in methods' parameters, which requires the ability to precisely specify this value chain. 

However, the naive approach of maintaining a representation of the whole application's dynamic state is irrealistic and inefficient, and leads to a killing overhead that hampers both the correct application execution and usability, and the quality of the policy enforcement, not to mention potential security breaches. \SAR opts for an intermediary solution: only the values of relevant dynamic artifacts are maintained, the rest is simply filtered out by considering static mappings and security rules definitions. We now detail the metamodels for the application's \emph{dynamic state} and the security \emph{rules status}, as depicted in Fig. \ref{fig:dynamic-state}. 


%\vspace{-0.5cm}
\subsubsection{Application's Dynamic State (AS)}
\label{sec:DynamicState}


\begin{figure}[t]
	\center
	\resizebox{\textwidth}{!}{\includegraphics{DynamicState.png}}	
	\caption{Dynamic State Abstract Meta-Representation}
	\label{fig:dynamic-state}
\end{figure}

The Dynamic State represents the values of relevant artifacts from the application, until a new \texttt{Event} occurs. An \texttt{Event} is either an \texttt{InstanceCrea\-tion}, which binds a new \texttt{instance} created in the application with its corresponding \texttt{Role}; or a \texttt{FieldUpdate}, which tracks fields' \texttt{Value} updates; or a \texttt{MethodCall}, which captures the artifacts involved in a method call: two references, \texttt{this} and \texttt{target}, tracks the caller and callee instances, and an ordered sequence of \texttt{Param}s stores the parameters' values. 

As an example, consider the creation of an instance \texttt{i} of (class) type \texttt{C}: if there is a class D involved in a \texttt{RoleDeclaration} of the form \textsf{\textbf{role} R \textbf{class} *.D}, and \texttt{D} is a superclass of \texttt{C}, then an \texttt{InstanceCreation} is created with \texttt{instance} referencing \texttt{i} and \texttt{role} referencing \texttt{R}. Note also that well-formedness rules apply for \texttt{FieldUpdate} and \texttt{MethodCall}: a field's value should conform to its declared type, and so for the caller, callee, and parameters types for a method call \cite{B:Gosling-etAl}. We assign an unique identifier for each method appearing in an \texttt{ActionDeclaration} to ease further reference (this is always possible in Java, despite the possibility of method overloading, since we consider method signatures in these declarations \cite[Sec. 8.4]{B:Gosling-etAl}).

%It consists of three information kinds: \texttt{Instance}, \textsf{ValueMapping} and \textsf{MethodCall}. An instance of the \textsf{Instance} class maps an \texttt{instance} of the application to its current \texttt{role}: it checks consistency with a \texttt{RoleDeclaration} \textsf{\textbf{role} R \textbf{class} *.D}, i.e. \texttt{D} should be a superclass of \texttt{instance}'s current type (remember that instances' types can be dynamically modified in Java using casting \cite{B:Gosling-etAl}). A \texttt{ValueMapping} is either a \texttt{FieldMapping} that maps the value of a relevant instance fields; or a \texttt{ParamMapping} that captures the value of a method's effective parameter. A \texttt{MethodCall} captures the artifacts involved in a method call: two references, \texttt{this} and \texttt{target}, tracks the caller and callee instances, and a ordered sequence of \texttt{ParamMapping} is used for tracking relevant parameter's values. For simplifying further references, we assign to each method an unique identifier (this is always possible in Java, despite the possibility of method overloading, if method signatures are considered \cite{B:Gosling-etAl}).

%captures the role type associated to a relevant application instance: for example, with a textual concrete syntax, if \texttt{\textbf{instance(}I, R\textbf{)}} is part of an application model, it expresses the fact that at this moment, the runtime instance \texttt{I}, whose class type is \texttt{C}, corresponds to the role \texttt{R}, because of a previous \texttt{RoleDeclaration} \textsf{\textbf{role} R \textbf{class} *.D}, where \textsf{D} is a superclass of \textsf{C}. An \texttt{ValueMapping} is either a \texttt{FieldMapping}that maps the value of a relevant instance fields; or a \texttt{ParamMapping} that captures the value of a method's effective parameter. A \texttt{MethodCall} captures method calls: two references, namely \textsf{this} and \texttt{target}, track the calling and the callee instances, whereas a \texttt{Param} this is usually used in combination with \texttt{MethodAtt} to also capture the relevant parameter values for this particular method call. Note that for simplifying method calls referencing, each method is assigned an unique identifier (this is always possible in Java, despite the possible overloading, if we consider method signatures \cite{B:Gosling-etAl}). 


\subsubsection{Rules Status (RS)}
\label{sec:RulesStatus}

The rules status is simply maintained by associated \texttt{RuleId} identifiers (cf. Fig. \ref{fig:rules}) with a \texttt{Status}, represented as an enumeration:   it can either be \texttt{\textsc{activated}}, \texttt{\textsc{violated}} (applicable only for obligations and prohibitions), or \texttt{\textsc{fullfilled}} (applicable only for obligations, to avoid their reactivation), or \texttt{\textsc{fviolated}}, meaning that an obligation is now fullfilled after being previously violated. The rule is also associated to a \texttt{source} and a \texttt{target} \texttt{Instance} that represent the roles involved in the rule's action (cf. Fig. \ref{fig:rules} for rule specification, which is used for defining well-formedness constraints).

%\begin{table*}[t]
%%\caption{Application State Predicates}
%\begin{tabularx}{\textwidth}{l p{1cm} l}
%\toprule 
%{\bf Predicate} &  & {\bf Informal Meaning} \\ 
%\midrule 
%instance\_of(i,r)& &$i$ is an instance of the class $r$ ($s$ is assigned the role of $r$)\\
 %
%attribute(i,n,v)& &$v$ is the value of the attribute $n$ of the instance $s$\\
 %
%method(i,m\_id) & &$i$ is an particular call (instance) of the method $m\_id$ \\ 
 %
%\comments{ 
 %\midrule 
%
%\multicolumn{2}{c}{$s,m \in \m{O}\;\;$ instance identifiers, $r\in \m{R}\;\;$ roles, $v\in \m{V}\;\;$ attribute values} \\ 
%\multicolumn{2}{c}{$n\in {N}\cup \mathds{N} \;\;$ attribute names and natural numbers, $m\_id\in \m{M} \;\;$ method identifiers}\\
%
%\multicolumn{2}{c}{
 %\begin{tabular}{c c c}
%$op$ & $\in$ & \(\begin{cases}
%
%\{=,<=,>=,<,>\},  & \text{if $n$ is an int, double, float, etc} \\
%\{equals, startsWith, contains\},  & \text{if $n$ is a String}\\
%\{is, includes\}, & \text{if $n$ is a collection, ArrayList, etc}\\ 
%\{is\}, & \text{if $n$ is a class in the target application}\\%, e.g. {\it sale, person, comment, etc}}\\ 
%
%
%\end{cases}\)\\
%\end{tabular}
%}\\
%}
 %\bottomrule
%
%\end{tabularx} 
%\label{table:applicationStatePredicates}
%
%\end{table*}

%\paragraph{Application State} To support contextual fine-grained security policies, we consider the {\it application state}. Figure \ref{figure_state} depicts the application state: it consists of a set of instances having attributes and values and a (possibly empty) policy action. A policy action consists of a set of method calls each having a set of parameters and a {\it this} and a {\it target} attributes. To enable the specification of conditions over the application state, we consider its representation using the three predicates shown and informally described in Figure~\ref{table:applicationStatePredicates}. 
%
%\begin{figure}[h]
%\center
%\includegraphics[width=10cm]{state.pdf} 
%\caption{The Application State}
%\label{figure_state}
%\end{figure}
%
%The predicate {\it attribute(i,n,v)} is used to describe the attributes of class instances and method parameters. For example, consider a fact {\it instance\_of(I,C)}. This fact means that {\it I} is an instance of {\it C} where {\it C} is a role identifier. A fact {\it attribute(I,N,V)} would mean that {\it V} is the value of the attribute {\it N} of {\it I}. Similarly, consider a fact {\it method(I,M)} where {\it M} is a method id. This fact means that {\it I} is an instance (a particular call) of {\it M}. A fact {\it attribute(I,P,V)} would mean that {\it V} is the value of the parameter having position {\it P} in {\it I}. Method calls have two additional special attributes namely a {\it this} attribute denoting the calling instance and a {\it target} attribute denoting the called instance of the method.
%
%For example, consider a method call to delete file with the following signature:
%
%\crsl{$deleteFile(int \;personID,\;String\; fileName)$}
%
%\noindent When this method is called it is described using a set of facts in the application state as follows:
%
%\crsl{ method(M,deleteFile), attribute(M,1,PersonID), attribute(M,2,FileName).} %{attribute(M,3,commentID), attribute(M,this,ModeratorID), attribute(M,target,CommentServiceID)}
%
%\noindent where {\it M} is a unique identifier of the method {\it PersonID, FileName} are the runtime values of the method call parameters.

%\paragraph{State Conditions} To simplify the specification of conditions over the application state, we overload the ternary predicate {\it attribute} and consider another quaternary predicate where the third argument is an operator. Some of the operators that we currently support are shown below. Note that it is straightforward to add support for other operators.
%
%\begin{table*}[h !t]
%%\caption{Application State Predicates}
%\begin{tabularx}{\textwidth}{l p{1cm} l}
%\toprule 
%{\bf Predicate} & & {\bf Informal Meaning} \\ 
%\midrule 

 
%attribute(i,n,op,v)& &$v$ is related to the value of the attribute $n$ of the instance \\
%&& $s$ according to operator $op$\\
 %
 %
 %\midrule 
%\comments{
%\multicolumn{3}{c}{$s,m \in \m{O}\;\;$ instance identifiers, $r\in \m{R}\;\;$ roles, $v\in \m{V}\;\;$ attribute values} \\ 
%\multicolumn{3}{c}{$n\in {N}\cup \mathds{N} \;\;$ attribute names and natural numbers, $m\_id\in \m{M} \;\;$ method identifiers}\\
%}
%\multicolumn{3}{c}{
 %\begin{tabular}{c c c}
%$op$ & $\in$ & \(\begin{cases}
%
%\{<=,>=,<,>\},  & \text{if $n$ is an int, double, float, etc} \\
%\{startsWith, contains\},  & \text{if $n$ is a String}\\
%\{includes\}, & \text{if $n$ is a collection, ArrayList, etc}
%
%\end{cases}\)\\
%\end{tabular}
%}\\
%
 %\bottomrule
%
%\end{tabularx} 
%\label{table:applicationStatePredicates}
%
%\end{table*}




%\comments{The call to the method 
%the messages exchanged between the classes of {\it Moderator, CommentService} and {\it Sale} needed to delete a comment in a sale. This message exchange consists of the following two methods:
%\begin{itemize}
%\item An object {\it Moderator} calls the method {\it deleteCo\-mm\-ent(int saleID, String personID, Comment comment)} where {\it saleID} is the ID of the sale moderator, {\it personID} is the ID of the moderator and {\it comment} is the comment to delete. 
%
%\item The object {\it CommentService} is the server, it uses the {\it saleID} to retrieve the {\it Sale} object from a list of sales and calls the method {\it Sale.deleteComment} to delete the comment. 
%\end{itemize}
 %}
 %
%\comments{
%\begin{figure*}[t]
%\centering
%\includegraphics[width= 12cm]{delete.pdf}
%\caption{Example2: Deleting a Comment}
%\label{figure_example_2}
%\end{figure*}
%}


